AQA Computer Science A level NEA Guidelines - Analysis

2017 Examiner’s report:

“There is encouragement that a student should gather details for the project from users via a dialogue of some form. Some of the interviews seen were very detailed and clearly gained relevant information for development of the project. Unfortunately, it was also common to see very short interviews which gathered no real requirements for the project to be assessed highly by centres. Students should be encouraged that in the interview it would be beneficial to ask probing questions to find out the real requirements of the user(s) and not just the kind of colours to be used or whether they like playing games.

The analysis should contain a list of the objectives set by the student for their technical solution. It was pleasing to see many students provide a detailed list of objectives that indicated both the requirements to be met and the complexity that this might involve. Students who submitted vague and brief objectives would struggle to pick up high marks in the analysis section and it would also be common for the rest of the project to suffer slightly. Weak objectives also make awarding the completeness mark hard as consideration must also be placed into what an A-level student would be expected to achieve.

The analysis section is to contain some modelling of the proposed system and it was pleasing to see students complete this in a variety of ways. Those projects that needed data processing usually included some discussion of the data required and DFD or ER diagrams. Students looking to produce a game sometimes struggled with the modelling section and also left the reader not understanding what their idea actually was. Students completing gaming projects could consider sketching out some ideas for the game and discussing the game flow as part of their modelling section.”

Guidelines:

Methods and sources: Students should be encouraged to use a range of appropriate methods and sources to research and investigate the problem, including websites, existing software, books, interviews, questionnaires, prototyping.

Relevant and genuine evidence should be presented in the report (most likely in an appendix, but referenced in the main report) but students should be discouraged from generating evidence unnecessarily or artificially.

Identifying a third party: It will be useful if a third party (that is someone other than the student) is involved in the analysis process. The third party might be a potential end-user of the software, such as a friend, relative, employee or teacher or somebody with knowledge, interest or expertise in the problem area. Their role is to support the student in investigating the problem, deciding upon the objectives and to give feedback, particularly at the end of the project.

Further research: It is accepted that the student’s depth of understanding of the problem will grow and develop as the project progresses. They should be encouraged to carry out further relevant research and after consultation with their teacher, refine and reassess their initial objectives as appropriate. The teacher should be the final arbiter and base their judgment on the initially agreed set of objectives and the scope appropriate for the abilities of the student and the nature of the project.

Prototyping and critical path: Prototyping the critical path at the analysis stage, early in the project development period, is encouraged so that changing objectives later on occurs only in exceptional circumstances, and with the agreement of the teacher. The achievement of the objectives will have an effect on determining the mark awarded for the coding of the project.

Required documentation for ‘Analysis’:

Check you have met all the following before submit your work!

Check List	Met
A clear statement that describes the problem area and the specific problem being solved / investigated. In other words, describe what your solution can perform, who is it for, what platform will it run on (PC, smart phone etc), how users will interact with it, is it client server model or standalone, etc.
An outline of how the problem was researched – online research or books of similar solutions and conclusions from your research that will help shape your objectives – what you liked not liked, why? What features you will like to incorporate and why?
A statement indicating who the problem is being solved / investigated for. Is it for specific group of users? Why?
Background in sufficient detail for a third party to understand the problem being solved / investigated. Why did you pick this problem? What this problem specifically address?
Any dialogues with the intended users such as interviews, surveys etc used to form your objectives. interview responses in a very structured manner with each question asked followed by a summary of the responses and then any specific objectives/requirements to be drawn from this question and response.
a numbered list of measurable, "appropriate" specific objectives, covering all required functionality of the solution or areas of investigation (‘appropriate’ means the specific objectives are single purpose and at a level of detail that is without ambiguity)
Any modelling of the problem that will inform the Design stage, for example a graph / network model of Facebook connections or an E-R model, state diagrams, scientific / mathematical models or formulae, data flow diagrams, a game play flow etc

Examples of Analysis and feedback from examiner

Example 1: Snakes and Ladders

Read the following work from a student:

Standardisationmaterials/SnakesAndLadders-analysis-1..pdf

Moderator’s feedback:

· Some research but not much dialogue

· Aims and objectives are weak (nothing to indicate algorithmic complexity)

· Moderated at 4

· Project decided as 'not A-level standard' - so mark reduced to 1

Example 2: Project Icarus

Read the following work from a student:

Standardisationmaterials/Icarus-analysis-2..pdf

Moderator’s feedback:

· A detailed analysis (lots of nice technical detail providing clear signposts to complexity)

· Good evidence of user involvement through dialogue.

· Excellent list of objectives - clearly separated, signposting techniques, SMART

· Perhaps lacks some modelling at the end of the analysis stage.

· Moderated at 8 but is 9 worthy

Example 3: Graph Tutor

Read the following work from a student:

Standardisationmaterials/GraphTutor-analysis-1..pdf

Moderator’s feedback:

· Good initial discussion over BFS, DFS and A*

· Not much dialogue with the user to inform decisions

· Objectives are broken down well

· Not much modelling at the end of the analysis section (however some work on classes)

· Not much detail in the analysis about how the key points made in the 'introduction' section are to be considered